1. Field of the Invention
The present invention relates to computer systems with novel input-output (I/O) architectures, and more particularly, and not by way of limitation, to a plug-and-play control mechanism for assigning and controlling one or more adapters.
2. Description of Related Art
A conventional computer system typically includes one or more central processing units (CPUs) capable of executing algorithms and one or more memory subsystems. Computer systems also include peripheral devices, or, peripherals, for inputting and outputting data. Some common peripheral devices include, for example, monitors, keyboards, printers, modems, hard disk drives, floppy disk drives, and network controllers. As known in the art, peripheral devices may be conveniently categorized into several classes based on their functionality. For example, the "block storage device" class of peripherals may include hard disk drives, whereas the "Local Area Network (LAN) ports" class may include LAN controllers, such as, for example, Ethernet controllers. The various components of a computer system communicate and transfer data using a bus system which is connected to the communicating components.
One of the key factors in the performance of a computer system is the speed at which the CPU operates. Generally, the faster the CPU operates, the faster the computer system can complete a designated task. Another method of increasing the speed of a computer system is using multiple CPUs, commonly known as multi-processing. With multiple CPUs, algorithms required to complete a task can be executed substantially in parallel as opposed to their sequential execution.
However, the addition of a faster CPU or additional CPUs can result in different increases in performance among different computer systems. Although it is the CPU that executes the algorithms required for performing a designated task, in many cases, it is the peripherals that are responsible for providing data to the CPU and storing or outputting the processed data from the CPU. When a CPU in operation attempts to read or write to a peripheral, the CPU often "sets aside" the algorithm which it is currently executing and is diverted to executing the read/write transaction (also referred to as an Input/Output transaction, or an I/O transaction) for the peripheral. As can be appreciated by those skilled in the art, the length of time that the CPU is diverted is typically dependent on the efficiency of the I/O transaction.
Although a faster CPU may accelerate the execution of an algorithm, a slow or inefficient I/O transaction process associated therewith would create a bottleneck in the overall performance of the computer system. As the CPU becomes faster, the amount of time executing algorithms becomes less of a limiting factor compared to the time expended in performing an I/O transaction. Accordingly, the improvement in the performance of the computer system that could theoretically result from the use of a faster CPU or the addition of another CPU may become substantially curtailed by the bottleneck created by I/O transactions. Moreover, it can be readily appreciated that any performance degradation due to such I/O bottlenecks in a single computer system may have a stifling effect on the overall performance of a computer network in which the computer system is disposed.
Operating peripheral devices in association with a computer system typically requires a piece of executable code, known commonly as a device driver. Because peripherals are often manufactured separately from the CPU, the operation of a peripheral is generally effectuated by a unique device driver associated with the specific peripheral. The device driver, which controls the peripheral, is an executable computer program that is executed by the CPU and must be compatible with the particular operating system (OS) of the computer system. It can be readily seen that because device drivers are unique to both operating systems as well as peripherals, a considerable number of device drivers are typically required to support the numerous possible combinations of peripherals and operating systems. Accordingly, it can be appreciated that the ensuing device driver proliferation thwarts the objective of device driver portability in the design of cross-platform computer system architectures.
Based on the foregoing discussion, it should be appreciated that current computer systems with a conventional I/O architecture utilizing device drivers described above suffer from a lack of device driver portability and performance constraints due to I/O bottlenecks. In order to address these shortcomings, an alternative I/O architecture--commonly known as the Intelligent Input/Output (I.sub.2 O) architecture--has been developed in the computer industry. Because the teachings of the present invention may be better described in relation to the I.sub.2 O architecture, a brief overview thereof is provided hereinbelow.
Essentially, the I.sub.2 O architecture uses a "split driver" model which inserts a messaging layer between the portion of the device driver specific to the operating system and the portion of the device driver specific to the peripheral device. It should be appreciated that in the parlance of the I.sub.2 O architecture, a peripheral device is also sometimes referred to as an adapter. Accordingly, henceforth, these two terms would be used somewhat interchangeably.
The messaging layer splits the single device driver of today into two separate modules--an Operating System Service Module (OSM) and a Downloadable Driver Module (DDM). The only interaction one module has with another module is through this messaging layer which provides the communication means.
The OSM comprises the portion of the device driver that is specific to the operating system. The OSM interfaces with the operating system of the computer system (which may also be referred to in the art as the "host operating system") and is executed by the host CPU or processor. Typically, a single OSM may be used to service a specific class of peripherals or adapter. For example, one OSM would be used to service all block storage devices, such as hard disk drives and CD-ROM drives. The DDM provides the peripheral-specific portion of the device driver that understands how to interface to the particular peripheral hardware. To execute the DDM, an I.sub.2 O Input/Output Processor (IOP) is added to the computer system. A single IOP may be associated with multiple peripherals, each controlled by a particular DDM, and containing its own operating system such as, for example, the I.sub.2 O Real-Time Operating System (iRTOS). The DDM directly controls the peripheral, and is executed by the IOP under the management of the iRTOS.
Those skilled in the art will recognize that a DDM may typically comprise a Hardware Device Module (HDM) that directly interfaces with the peripheral and is responsible for its control and data transfer associated therewith. DDMs can also comprise an Intermediate Service Module (ISM) which is an additional software interface to the HDM. The ISM is often used for filtering, encoding, and decoding messages to the HDM.
In general operation, the communication model used in the I.sub.2 O architecture is a message passing system. When the CPU seeks to read or write to an adapter or peripheral in an I.sub.2 O system, the host operating system makes what is known as a "request". The OSM translates the request by the host operating system and, in turn, generates a message. The OSM sends the message across the messaging layer to the DDM associated with the peripheral which processes it appropriately to achieve a result. Upon completion of the processing, the DDM sends the result back to the OSM by sending an appropriate message through the messaging layer. It can be appreciated that to the host operating system, the OSM appears just like any other device driver.
By executing the DDM on the IOP, the time-consuming portion of transferring information from and to the peripheral hardware is off-loaded from the CPU to the IOP. With this off-loading, the CPU is no longer diverted for inordinate amounts of time during an I/O transaction. Moreover, because the IOP is a hardware component essentially dedicated to the processing of the I/O transactions, the problem of I/O bottlenecks is mitigated.
The I.sub.2 O architecture also significantly reduces the number of device drivers written on the basis of the split driver model. Typically, peripheral device manufacturers need only write a single DDM for a particular peripheral which can now operate with any host operating system. The vendors of the host operating system need only write one OSM for each class of peripherals, e.g., the network controller class.
One of the goals of the I.sub.2 O architecture is to allow standard "non-intelligent" or "semi-intelligent" peripheral devices to be controlled by a generic I.sub.2 O IOP resource (for example, an I.sub.2 O "accelerator" card) that could be added to a computing system. If the IOP contains the necessary software to control a particular peripheral device, the device may be abstracted through the IOP to "look" like an intelligent I.sub.2 O peripheral or adapter.
According to the I.sub.2 O architecture's specification, an IOP can control two types of adapters: hidden and system. A hidden adapter is typically one that does not appear in the system's configuration, I/O or memory address space. Such an adapter will not be seen by legacy configuration software. A system adapter, typically, is one that can appear in the system's address space, but may be controlled by the IOP. Since the device is visible to system software, care must be taken to prevent such software from interfering with control software running on the IOP.
Furthermore, it can be appreciated that in current technologies adapters or adapter slots/locations are also commonly categorized into two groups based on their topological arrangement. At present, two common architecture types are prevalent in computer systems. In one type, the system may typically comprise a primary I/O bus (such as, e.g., a Peripheral Component Interconnect bus, or, PCI bus) that is bridged to a 1S secondary I/O bus (such as, e.g., a PCI bus). In a second type, the system may comprise peer-level I/O buses bridged to a host bus, wherein additional I/O buses may be hierarchically coupled via suitable bridges to the peer-level buses. Moreover, in either architectural types, the bus bridging devices may typically comprise an IOP. Accordingly, it should be understood that adapter slots/locations may be conveniently referenced with respect to the location of the IOP/bridge device. For example, adapters or adapter locations/slots provided on a bus segment that is positioned in front of an IOP/bridge ("primary-side" bus) may be generally referred to as "primary-side" or "front-side" adapters or locations. Similarly, adapters or locations disposed on a bus segment that is positioned behind the IOP/bridge ("secondary-side" bus) may be termed as "secondary-side" or "back-side" adapters or locations.
In order for the IOP to control an adapter, two conditions are generally required. First, the adapter must be assigned to the IOP. Secondly, the IOP must contain a suitable DDM/HDM for the assigned device. Typically, if both of these conditions are met, the device is under IOP control. In current systems, the assignment characteristics, inter alia, of adapters or slots are typically defined in a non-volatile data construct (called "Hardware Resource Table" or "HRT") associated with the IOP. It can be readily appreciated that typically the assignment state of an adapter/slot may be, accordingly, remembered across boots once it is defined or programmed. However, at the first instance of system initialization (that is, when an IOP resource is initally added to the system), the contents of the HRT are unknown and the adapter assignment, therefore, is undefined and somewhat ambiguous. Typically, secondary-side or back-side adapters or locations (that is, adapters behind the IOP) are designated upon system initialization as "assigned" to the IOP resource. Similarly, primary-side or front-side adapters or locations are designated as "unassigned". Such default treatment of the adapter slots/locations may be overridden by setting a switch in the iRTOS.
Typically, in current systems, when an adapter is marked as "assigned" by setting an appropriate bit or flag in the HRT, interrupts from the device are routed to the IOP, whether or not the IOP is loaded with a suitable driver module therefor. Only when a suitable driver module is found for the adapter, it will be controlled by the IOP. It can be appreciated that in ideal situations adapters should not be assigned to the IOP unless the IOP is capable of controlling them. Currently, the front-side adapters are defaulted to the "unassigned" state and host configuration software would then use a procedure (for example, the ExecAdapterAssign procedure) for adapters that have suitable driver modules on the IOP.
There are several shortcomings in this approach which give rise to various performance costs and constraints. First, current solutions for "designing around" the initial default treatment of adapters/slots is extremely cumbersome and non-intuitive. For example, there is no simple way for the host to determine which adapters an IOP is capable of controlling and which adapters it is not, since, that determination is typically done by the IOP and not the host. To circumvent this situation, the host would first have to assign an adapter/slot to the IOP and then look to see if it was controlled. If it was not, for some reason--e.g., lack of a suitable DDM/HDM--the host would have to release that adapter/slot. Typically, this procedure needs to be done every time a DDM was downloaded, of which again, the host has no knowledge. Essentially, the system ROM would have to enumerate every adapter/slot controllable by the IOP, assign it to the IOP, retrieve the updated HRT to see if the adapter was a controlled adapter (that is, controlled by the IOP), and unassign or release it if it wasn't. It can be readily appreciated that while this procedure might work, it is highly cumbersome and not user-friendly. Moreover, in spite of the workability of this solution, there is no efficient and effective method to force adapters that are capable of being controlled from not being automatically assigned to the IOP (that is, although the IOP may contain a driver for an adapter, the user may not want the IOP to control it).
Also, if any assignment changes were necessary subsequently, the ROM would have to force a system reset since controlled adapters must be hidden to prevent non-I.sub.2 O aware host drivers from contending with the device. While an adapter can be assigned manually through an appropriate configuration procedure (for example, the IOPSETUP procedure) this requires the user to pick from a list of devices identified only by their BUS ID (e.g., PCI ID). Again, it should be appreciated that such procedures are unwieldy, awkward and non-intuitive from a user's perspective.